-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix addMainModuleInfo
erroneously considered UP-TO-DATE
#17
base: master
Are you sure you want to change the base?
Conversation
The addMainModuleInfo task replaces the original JAR with a modifies JAR. However, previously it did not properly specify the task inputs, therefore it was erroneously considered UP-TO-DATE even if the JAR changed. Note that now unfortunately the `jar` task is always run and never considered UP-TO-DATE because addMainModuleInfo modified the original JAR.
abstract String getShortName() | ||
@InputFile | ||
abstract File getInputJar() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have not specified @PathSensitive(PathSensitivity.NONE)
here because for AddMainModuleInfoTask
the path matters since the file is overwritten.
I hope this does not cause issues for ModuleConfiguration
which overrides this method and adds its own annotations.
@@ -100,7 +100,6 @@ class ModuleConfiguration extends AbstractModuleConfiguration { | |||
primaryArtifact.file | |||
} | |||
|
|||
@Input |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this is redundant because the overridden method already defines this (but have not tested this!).
@Input | ||
String group | ||
@Input |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense to define these as inputs, but I have not tested this.
abstract String getVersion() | ||
@Nested |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have not tested this.
The
addMainModuleInfo
task replaces the original JAR with a modifies JAR. However, previously it did not properly specify the task inputs, therefore it was erroneously considered UP-TO-DATE even if the JAR changed.Note that now unfortunately the
jar
task is always run and never considered UP-TO-DATE becauseaddMainModuleInfo
modified the original JAR. Not sure if that can be solved in a cleaner way. Though interestingly manually specifying the JAR in thebuild.gradle.kts
withinputs.file(mainModule.get().inputJar)
does not cause thejar
task to be re-run (though maybe that also depends on the Gradle version being used).I am not that familiar with Gradle so any feedback is appreciated!
Note that there are some parts which I have not tested; if you want I can omit those and only add the annotations necessary for
getInputJar()
.